Interdisciplinary Insights on Open Source

The term “open source” is widely applied to describe some software development methodologies. This paper does not provide a judgment on the open source approach, but exposes the fact that simply stating that a project is open source does not provide a precise description of the approach used to support the project. By taking a multi- disciplinary point of view, we propose a collection of characteristics that are common, as well as some that vary among open source projects. The set of open source characteristics we found can be used as a tick-list both for analysing and for setting up open source projects. Our tick-list also provides a starting point for understanding the many meanings of the term open source

Dependability Issues in Open Source Software - DIRC Project Activity 5 Final Report

This report presents the findings of this investigation by reporting on the main activities that have been undertaken and presenting our informed final recommendation on a follow-on project activity. It is structured in the following way. Section 2 explains the obstacles encountered while trying to understand the term "open source", contacts pursued and projects observed with respect to open source. Section 3 presents insights into the sociology of open source software development, whereas section 4 describes observations drawn and main issues identified for open source software development and dependable systems engineering. Finally, section 5 explains our recommendation together with the reasons behind our decision. Further insights on the activities described in this report, as well as various papers that have been written in relation to this activity can be found in the appendices A - E

Distribution unlimited.

Approved for public release

Automatically detecting mismatches during component-based and model-based development

A major emphasis in software development is placed on identifying and reconciling architectural and design mismatches. Those mismatches happen during software development on two levels: while composing system components (e.g. COTS or in-house developed) and while reconciling view perspectives. Composing components into a system and ’composing ’ views (e.g. diagrams) into a system model are often seen as being somewhat distinct aspects of software development, however, as this work shows, their approaches in detecting mismatches complement each other very well. In both cases, the composition process may result in mismatches that are caused by clashes between development artefacts. Our component-based integration approach is more high-level and can be used early on for risk assessment while little information is available. Model-based integration, on the other hand needs more information to start with but is more precise and can handle large amounts of redundant information. This paper describes both integration approaches and discusses their commonalties and differences. Both integration approaches are automateable and some tools support is already available